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i July 1970 


MEMORANDUM FOR; Director of Security 

SUBJECT ; Comment* on Proposed DCXD entitled ’‘Minimum 

Security Requirement* for Multi-Level 
Operation of Resource Sharing Computer : 
System* in a Benign Environment" 


1 . I agree with the Intent, the security concepts, and with 
most of the proposed requirements of the proposed DC3D, hut I do 
not concur in the draft in its present form. My main criticism is ^ 
in the wording of several sections --more specifically with three 
areas of definition which need more careful and precise language 
before a policy of such far-reaching consequences is promulgated; 

— The computer environment for which the policy is to apply 
is not described consistently throughout the paper. 

--The term ’'multi-level’* is not used consistently. Indeed 
the concept of security "levels’* is not clear. 

—The words used in the draft to describe requirements 

relating to authorisation to use these computer systems 
are not applied with sufficient care, 

2. The specific comments below deal mostly with such 
questions of wording. The draft is a good start; particularly note- 
worthy is the absence of technical jargon. I believe the necessary 
time should be taken to do a good editing job, regardless of deadlines 
previously established. 

a. The paper fails to distinguish clearly between the 

use of a computing system in which the user has remote 
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access and the operation of a closed-shop computing center 
in which the normal operating system being used allows for 
the running of more than one program concurrently. This 
problem Is illustrated in the first definition on page 7: The 
terms "multiprogrammed" and "multiprocessing" are used; 
these terms do not necessarily imply "remotely accessed". 
Again on page 14 the term "remote batch mode" is used and 
specific requirements are stated for this method of operation* 
as distinguished from the interactive terminal mode. The 
reasons for ibis distinct ion are not given; indeed the defini- 
tion of remote batch mode is not given anywhere in the paper. 
It is imperative that the environment for which the policy Is 
to apply be more precisely defined before OCS attempts to 
judge the practicality of some of the requirements. For 
example, our ability to meet the user identification /authenti- 
cation requirements (para. 6 (b), page 14) depends on 
whether the environment is defined to include multi-program- 
ming. 

b. At some points in the paper there is an attempt to 
distinguish between "multi-level" and "compartmented" 
information. At other points the distinction between these 
two terms is not made. The wording used at the beginning 
of paragraph 6 (page 13) is an illustration of the confusion 
which results from an attempt to distinguish between "levels* 1 
and "compartments tion". If interpreted literally, the 
requirement* of this paragraph would not apply to compart- 
ment ed data at the same security level. Another example of 
the confusion is in paragraph 3 (Physical Security Protection) 
on page 12, It is stated that "the computer center area 
requirements shall fee based on the highest level of the total 
system; remote terminal area requirements depend on the 
highest level of information designated for input/output at 
each terminal. But paragraph 3, page 7, says a benign 
environment ia one with protection and control at the top 
secret level. If the ''highest level" of data Is below top 
secret, which of the two statements applies? The same 
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question could be asked concerning the requirement for 
protection of communication link* at the top secret level 
(page 12) If the data to be transmitted i* below that level. 

The use of the term "multi- security level" on page Z 
confuse* the matter further. The need for two different 
terms --"multi -level" and ’’compart men ted "--is question- 
able. The important point i* to provide for adequate separa- 
tion of information within a system when creators or user* 
of such information feel that such separation is necessary. 
Perhaps the term "compartmenfcatien" or "compartmenied 
information" is adequate in all the appropriate places in 
the paper in lien of "multi-level". T 

c. The following terms are used in the paper to denote , 
the concept of authorisation to access the computer system: 
access authorisation (page 11), authentication (page 11), 
access control passwords (page 11), access approval* 

(page 11), designated personnel (page 12), user identifica- 
tion/authentication (page 14), authorisation codes (page 14), 
authorised requestor (page 14), access control (page 15), 
passwords (page 1 5), user access list (page 15), access 
limitations (page 16), user authorization (page 16). In some ? 
cases these words are used a* synonyms, in other cases 

one can infar that there is a distinction between these words. „ 

d. The paper isaddressed to the "benign environment*', 
but in some places the paper implies the need for protection 
against "deliberate unauthorized Intrusion** (page 6) and 
"unauthorized probes** (page 14). The connotation of "benign" 
can be misleading; perhaps a better choice is "nan-hostile". 

3; The most crucial part of the proposed DCID Is paragraph 6 
beginning on page 13. Specific comments are made below on each of 
required feature# (as identified by sub-paragraph): 


a. Although detail is given on the requirement to include 
security indicators, there is no purpose given for this 

requirement. 
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b. The wording used in the initial sentence of this 
paragraph is much too confusing; it needs to be simplified. 
The special requirements noted for ''remote batch mode*' 
should be stated differently so they will apply for all remote 
users. That is, if there are procedures which permit the 
user to leave the area while the computer is still working 
an his task (regardless of the kind of terminal involved), 
there also should be a procedure to insure that the computer 
output is delivered only to him when he returns. Finally, 
the requirement to identify a specific user with a specific 
terminal will be unwieldy in CIA Headquarters since it Is 
intended that terminal "service centers'* be established for 
general use of anyone in the area. Also the practice of 
going to the nearest available terminal has already been 
well accepted and the security procedures now in force seam 
to provide adequate control. 

c. This requirement assumes that core la shared among 
several user programs. Under some operating systems this 
may not be the case. More importantly, PCS cannot meet 
this requirement for most of its equipment without special 
changes made by the manufacturer? 

d. The wording of this requirement, as well as others 
to be met by hardware functions, tacitly assumes that 
verification of correct operation of these functions is not 
only possible but also practical. To the contrary, this is 

a substantial effort in its own right. This is true both of 
the initial verification that the features do in fact operate 
as they are designed to operate and also for the continuing 
inspection of these features to determine that they have not 
been subverted or circumvented. Bather than use the strict 
language proposed, it might be better to state these as 
explicit design goals and add a general statement elsewhere 
on the hardware/software reliability problem. 


TTf' 


®ECli2. 


r 
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*. The wording used here need# to he drastically 
revised: what does the term ''independent hardware 
mean? How is -disposable residue- distinguished from 
-undis posable residue*'? What is meant by the term 
auxiliary memory? ” 

f The word -software- on the second line should 1>« 
deleted. The use of the term -selected- implies that some 
files can be used without any -access control - Is this 
correct? CCS cannot ad equately meet the requirement 
for controlling readiwrlte au t hority with its present «<? £ - - 
nor with any other known softwar e suitable for jts, 

environment . 

g To obtain a -complete listing of personnel attempting 
to gain acc...” would reqalra th. coop.ratioa of hoatiUa. 

Xha last santanaa of tht« »<*- paragraph might battar Ua 
included tinder the security officer duties on page 1 1 . 

h. The * direct control" to be exercisdd by the system 
security officer in modifying software security feature* ia 
impossible to guarantee; no one can make the c!aim a 
operating system can be rendered completely invuinembe 

to attempts to modify it by user program.. I,J\^!^rded 
this paragraph should he retained* but it should be reworded 
to take into account the current state-of-the-art in operating 

systems. 

4 The proposed maximum delay in effecting this policy 

(1 January 1971) is impractical for CCS and ^If**** ****** 

L CIA as well. While most of the requirements of this 

directive have been or can be met, there needs to be eu-fleient time 

for training security personnel, computer L L “ ye 

designers, and to insure that all provisions of this directive are 

being applied in fact as well as in spirit. ^ 

CASTS. DUCKETT 
Deputy Director 
for 

Science and Technology 
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9 July 1970 


TRAINING 

Because the numbers of ADEPT students destined to become 
full-time p computer programmers had been lessening 

with each running of the course, it was decided to refiew 
the ggE goals and selection criteria for enrolling students 
in the 15-week OCS course in basic programming (ADEPT) . 

It was decided to initiate a more modest 5-week course 
"Introduction to Computer Programming" beginning 9 Nov 1970 
to be slanted toward those who needed in depth knowledge 
in programming but azoncfcdcHotc were not besing groomed 
for full-time programmer jobs. The IgC's of all directorates 
were advised to screen applicants for both courses by 
administering the Brandon-Wolf e Test (Aptitude Assessment 
Battery: Programming) and the IBM Programmer’s Aptitude 
Test (PAT) to help determine the individual's potential 
and performance and use results of these tests in making 
selections for the two courses; and also that attendance 
at the 15-week ADEPT course be limited to those expected 
to fill positions as full-time computer programmers. 


Approved For Release 2004/06/29 : CIA-RDP85B00803R000200080072-6 



Approved For Release 2004/06/29 : CIA-RDP85B^8$#^6o 
PLANNING QUESTIONNAIRE 


So72^0 7^ ^ 





STAT 


10 July 1970 

Response to a customer questionnaire relating to their 
usage of remote terminals in the interactive computer 
system brought out the following information: 

Uses being made of the system: 


Programming tasks 47 customers 

Information retrieval 38 " 

Calculations 30 " 

~~]T S' 


Cu stomers were asked, in view of the cost of th e 360/67 


of 


whether 


in 


10 


their experience so far had been satisfactory or not. 
Replies were as follows: 

7 Has not paid off and intend to stop terminal use 
Has not paid off but have no alternative but 
to continue using it 
Has not paid off yet but expect it will 
Has paid off but needs improvement 
lHas paid off and basically satisfied with system 
Note, 73% indicated the system was paying off for them. 



One of the principal complaints was need for better, or 
more consistent , response time, in order to increase the 
payoff of the interactive services. 


A good deal of information was received from the customer 
replies which was helpful in planning for the future. 
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COINS 5 August 1970 


Current participation in COINS limited to 3 hrs a dav 
on the IBM 360/67. This costs about [ 


besides which the system is lost to those Agency 
components which had begun to depend on it for on-lim 
program development, file handling and computational 
support. 


STAT 


recommended the Agency acquire a separate 

computer to be devoted to COINS and other external access 
applications full time. He assumed the Director of Security 
would continue to riesHfat advise against storing Agency-sensitive 
data m a computer which has a possible data path to an 
uncontrolldd terminal. It appeared that two distinct physical 
systems would be necessary, principally to avoid the risk of 
sensitive Agency data accidentally being disclosed outside 


— , | felt the CRS should operate the COINS computer, 

and should have the choice of selecting the type of computer 
and developing the software. 
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10 Aug 1970, I I recommended placing the burden of 

security on the individual agency through procedures which would 


STAT 





